Skip to content

chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - #153

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 18, 2026 •

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Type Update Change OpenSSF
github.com/gruntwork-io/terragrunt indirect major v0.82.0 → v1.1.1 OpenSSF Scorecard

Terragrunt: Arbitrary File Deletion via Malicious Module Manifest

CVE-2026-45099 / GHSA-8394-6f8r-whxg / GO-2026-6241

More information

Details

Summary

Terragrunt is vulnerable to an arbitrary file deletion flaw when downloading external modules. If a remote module contains a maliciously crafted .terragrunt-module-manifest file, Terragrunt can be tricked into deleting files anywhere on the local filesystem that the Terragrunt process has access to.

Impact

This vulnerability impacts users who download and run untrusted or compromised OpenTofu/Terraform modules. The file deletion occurs during the module download and initialization phase, meaning it happens before OpenTofu or Terraform executes.

In a CI/CD environment or automated runner, an attacker-controlled module could delete arbitrary files, causing denial of service in the deployment pipeline. In a local environment, it could lead to the loss of local source code or configuration files.

This vulnerability is a deletion-only primitive; it does not directly allow for arbitrary code execution (RCE) or data exfiltration.

Affected Versions
  • Terragrunt < v1.0.4
Patches

This vulnerability has been resolved in Terragrunt version v1.0.4.

All users are strongly advised to upgrade.

Workarounds

If users cannot upgrade immediately, they can mitigate this risk by:

  1. Strictly auditing the source URLs of all remote modules used in their Terragrunt configurations.
  2. Only consuming modules from trusted, internally vetted sources or verified registries.
  3. Pinning module versions to specific, known-safe Git commit SHAs rather than mutable tags or branches.
Technical Details

Terragrunt tracks files copied into a downloaded module's working directory using a .terragrunt-module-manifest file. During the directory cleanup process, Terragrunt decodes the entries in this manifest and removes the listed files to prepare a fresh directory for OpenTofu/Terraform runs.

Previously, Terragrunt trusted the manifest provided by the downloaded module without verifying that the paths scheduled for deletion remained within the boundaries of the module's destination directory. An attacker could forge a manifest containing directory traversal paths, causing the cleanup function to target files outside the cache. The patch introduces a secure boundary check to ensure all cleaned paths remain safely isolated inside the intended manifest folder.

Credit

Terragrunt would like to thank Francesco Sabiu (@​fsabiu) for discovering and responsibly disclosing this vulnerability.

Severity

  • CVSS Score: 6.9 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Terragrunt: Arbitrary File Deletion via Malicious Module Manifest in github.com/gruntwork-io/terragrunt

CVE-2026-45099 / GHSA-8394-6f8r-whxg / GO-2026-6241

More information

Details

Terragrunt: Arbitrary File Deletion via Malicious Module Manifest in github.com/gruntwork-io/terragrunt

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).


Terragrunt catalog predictable temp symlink clobber

CVE-2026-64672 / GHSA-wv6g-x823-wx9m / GO-2026-6768

More information

Details

Summary

Terragrunt's terragrunt catalog command clones each repository referenced in your catalog configuration into a temporary working directory. In affected versions, the clone path it derived was deterministic and sat under the shared system temporary directory, in the form <tmp>/catalog-<base64 sha1 of the repo URL>. Because that path was predictable and Terragrunt followed a symlink already present there instead of rejecting it, a local attacker could plant a symlink at that path and cause Terragrunt to delete a directory and re-clone into it outside the intended temporary root.

Impact

This affected users who ran terragrunt catalog on a host they shared with other local users or processes they did not fully trust, such as a multi-user server or a shared CI runner. The attack required a local attacker: a separate local user or process able to write to the shared system temporary directory. It was not remotely exploitable, and the victim had to run terragrunt catalog while the attacker's symlink was already in place.

Because the predictable path depended only on the repository URL being cataloged and the location of the system temporary directory, the attacker could compute it in advance and plant a symlink there before the victim ran the command. When the victim ran terragrunt catalog, Terragrunt followed the symlink out of the intended temporary root, deleted an existing <repoName> directory under the attacker-chosen parent, and repopulated that path with the cloned repository contents. All of this happened in the security context of the user running Terragrunt.

The attacker controlled the parent directory the symlink pointed to, but not the leaf name: the leaf was fixed to <repoName>, derived from the repository URL the victim cataloged. The primitive was deletion of an existing <repoName> directory outside the temporary root, followed by a re-clone into that same path. On a single-user machine with no hostile local processes, exposure was minimal.

Affected Versions
  • Terragrunt < v1.1.1
Patches

This vulnerability has been resolved in Terragrunt version v1.1.1.

All users are strongly advised to upgrade.

Workarounds

If you cannot upgrade immediately, ensure that you do not allow untrusted parties to control the values of TMPDIR, TMP, and TEMP in environments where you run terragrunt catalog.

Technical Details

When you run terragrunt catalog, the catalog service iterates over the repositories in your configuration and prepares a local clone of each one. In affected versions, for a given repository URL it built a clone path by hashing the URL and joining the result under the shared system temporary directory:

<tmp>/catalog-<base64 sha1 of the repo URL>

This path was fully determined by the repository URL and the location of the system temporary directory, so anyone else on the machine who knew which repository a victim would catalog could compute it in advance. The catalog service passed this path into its clone preparation step.

As a result, an attacker who placed a symlink at <tmp>/catalog-<hash> pointing at a directory of their choosing caused both the removal and the re-clone to operate through that symlink. Both landed at <attacker-chosen-parent>/<repoName>, outside the intended temporary root.

Terragrunt v1.1.1 no longer derives a predictable clone path, so an attacker can no longer position a symlink at a location known in advance.

Credit

We would like to thank (@​br0x2) for discovering and responsibly disclosing this vulnerability.

Severity

  • CVSS Score: 4.4 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Terragrunt catalog predictable temp symlink clobber in github.com/gruntwork-io/terragrunt

CVE-2026-64672 / GHSA-wv6g-x823-wx9m / GO-2026-6768

More information

Details

Terragrunt catalog predictable temp symlink clobber in github.com/gruntwork-io/terragrunt

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).


Release Notes

gruntwork-io/terragrunt (github.com/gruntwork-io/terragrunt)

v1.1.1

Compare Source

🐛 Bug Fixes

Chained role assumption for the S3 backend

When AWS credentials were supplied through --auth-provider-cmd or environment variables, Terragrunt ignored the assume_role attribute of the remote_state block for its own backend operations, such as bootstrapping the state bucket. In cross-account setups this caused access errors, even though OpenTofu/Terraform itself assumed the role correctly during runs.

Terragrunt now uses the supplied credentials as the source identity and assumes the configured role on top of them. The same applies to roles configured via the iam_role attribute or the --iam-assume-role flag, and to fetching dependency outputs directly from S3 state.

Safer temporary clone directories for terragrunt catalog

Terragrunt now creates a fresh temporary clone directory for each catalog load, rejects symlinked clone roots, and removes catalog clones when the TUI session exits.

Resolve dependency outputs for units that reference a dependency in a hook, extra_arguments, or remote_state block

Resolving a unit's dependency outputs for a downstream unit no longer fails when that unit references its own dependency in:

  • a before_hook, after_hook, or error_hook
  • an extra_arguments block
  • a remote_state block

Previously these raised There is no variable named "dependency" on the downstream unit, and a remote_state reference could crash Terragrunt.

Limit IaC engine archive extraction

Terragrunt now protects developer machines and CI runners from engine archives that expand into unexpectedly large amounts of data. If an IaC engine package is unusually large or contains too many files, Terragrunt stops processing it before it can consume excessive disk space.

--filter-allow-destroy with ...[] dependent-traversal filters no longer fails

--filter-allow-destroy --filter '...[HEAD~1...HEAD]' failed with "Too many command line arguments" or hung when the deleted unit had dependents. Terragrunt now correctly plans and destroys deleted units regardless of whether dependents are included in the run.

Fix find and list missing units inside generated stacks for Git-based filters

terragrunt find and terragrunt list with a Git-based filter (for example --filter '[HEAD^1...HEAD]') now detect units inside generated stacks. Previously they did not generate stacks in the worktrees they create for the comparison, so no unit nested in a generated stack was ever surfaced, while terragrunt run --all with the same filter targeted those units correctly.

This affected every change that lands inside a generated stack, including a modified terragrunt.stack.hcl, a change to a unit's own files, and a change to a file the stack reads via read_terragrunt_config or mark_glob_as_read.

Stacks are generated only inside the comparison worktrees; find and list still do not generate stacks in your current working directory by default.

Treat Git source ref values strictly as references

Terragrunt now passes the ref from a Git module source to git strictly as a reference when downloading through content-addressable storage. Previously a source whose ref began with a git option (for example a value starting with --) could be interpreted by git as an option rather than a reference while fetching the source.

Terragrunt now terminates git option parsing before the repository and reference arguments in its fetch, clone, and ls-remote invocations, so these values can only ever be read as the repository and reference they are meant to be. Normal refs, branches, tags, and commit SHAs continue to work unchanged.

hcl validate resolves get_original_terragrunt_dir() to the discovered unit

terragrunt hcl validate and terragrunt hcl validate --inputs now resolve get_original_terragrunt_dir() to each discovered unit's own directory instead of the directory the command was launched from. Previously, when the command ran from a parent directory that discovered units in subdirectories, any read_terragrunt_config() call that built a path relative to get_original_terragrunt_dir() resolved against the wrong directory and failed with "You attempted to run terragrunt in a folder that does not contain a terragrunt.hcl file", even though plan, apply, and run validate worked on the same configuration.

Both commands now set the original config path per discovered unit before parsing, matching the behavior of run and backend bootstrap, so relative paths resolve against the unit that owns them.

Respect -lockfile=readonly during provider caching

When you pass -lockfile=readonly to init, Terragrunt no longer generates or updates .terraform.lock.hcl while warming the provider cache. Previously the cache step could write the lock file before OpenTofu/Terraform ran, so the read-only check always passed and silently defeated the flag.

Terragrunt now leaves the lock file untouched and lets OpenTofu/Terraform enforce it, failing when the lock file is missing or incomplete. The flag is honored whether it is supplied on the command line or through the TF_CLI_ARGS or TF_CLI_ARGS_init environment variables.

run --all no longer crashes on dependency discovery with graph filters

Running run --all with a filter that expands a git range through the dependency graph (for example [HEAD~1...HEAD]...) could fail during dependency discovery, reporting that a component "is missing its working directory". Whether it happened depended on the size and shape of the changed unit's dependency closure, so the same filter succeeded on smaller branches and find was unaffected.

A dependency reached from several units at once could become visible to discovery before its working directory was set, so a concurrent traversal could read it before it was complete. Dependencies now have their working directory set before they become visible, so run --all behaves the same regardless of graph size.

terraform_binary respected by run --all when both tofu and terraform are on PATH

run --all ignored a unit's terraform_binary setting and fell back to the auto-detected default (OpenTofu when both binaries are on PATH). The per-unit options used to execute each unit are cloned from the stack options, whose binary path is the auto-detected default, and the configured value was never applied to them.

Each unit now honors its own terraform_binary, matching the behavior of a single run. Setting --tf-path or TG_TF_PATH still takes precedence over the config value.

S3 bucket creation failures report the underlying error

When creating the state bucket failed during backend bootstrap, the reported error was a misleading NoSuchBucket from a follow-up access check, hiding the actual cause. The original creation error, such as AccessDenied, is now part of the reported message.

Allow empty locals blocks in terragrunt.stack.hcl

Fixed a bug where an empty locals {} block in a stack configuration could break stack generate.

Clear error when terraform.source references a dependency output

A terraform.source that references dependency.<name>.outputs.<key> is now rejected with a message explaining that the module source must be resolvable before dependencies are evaluated.

Terragrunt resolves the source while discovering units and building the run queue, before any dependency has run, so such a source can never be satisfied. Previously it surfaced a cryptic decode error.

🧪 Experiments Added

oci - Module sources from OCI registries

The oci experiment has been added as the gate for downloading source code (including OpenTofu modules) from OCI Distribution registries using oci:// schema URLs in Terragrunt configurations (including terraform.source attributes). This targets the same registries OpenTofu 1.10 supports natively, such as Amazon ECR, GitHub Container Registry, Azure Container Registry, Google Artifact Registry, and self-hosted or air-gapped registries.

Enabling the experiment has no behavioral effect yet: the getter that will resolve oci:// sources is not wired into source downloading, so oci:// sources still fail to download. Functional support will land in follow-up releases, gated by this experiment.

For setup steps, see the experiment documentation.

version-attribute - Resolve registry modules from a version constraint

The version-attribute experiment has been added to gate a new version attribute on the terraform block. It holds a version constraint (such as ~> 3.3 or >= 1.0.0, < 2.0.0) for a tfr:// registry module, and Terragrunt resolves it to the highest published version that satisfies the constraint before downloading:

terraform {
  source  = "tfr://registry.opentofu.org/terraform-aws-modules/vpc/aws"
  version = "~> 3.3"
}

This brings the terraform block to parity with the version argument on OpenTofu and Terraform module blocks. The attribute applies to tfr:// sources only, and cannot be combined with an inline ?version= on the same source.

Enable it with --experiment version-attribute. For setup steps and the criteria for stabilization, see the experiment documentation.

⚙️ Process Updates

Friendly panic reports

Terragrunt now writes a terragrunt-crash-YYYYMMDDTHHMMSSZ-<pid>.log file when it crashes.

The report includes runtime details, the command line, the panic message, and the stack trace. You can conveniently share this file (after reviewing for sensitive information) to report panics if Terragrunt crashes.

Pull Requests

✨ Features
🐛 Bug Fixes
📖 Documentation
🧹 Chores
📝 Other Changes
  • Revert "chore(deps): bump the js-dependencies group across 1 directory with 4…" by @​yhakbar in #​6433

v1.1.0

Compare Source

✨ New Features

Stack dependencies

A stack generates a tree of units from a single terragrunt.stack.hcl file. Wiring one of those units to another used to mean defining dependency blocks in your catalog and threading dependency paths through values. Stack dependencies let you declare those relationships up front instead.

Add an autoinclude block inside a unit or stack block, and Terragrunt generates a partial configuration (a terragrunt.autoinclude.hcl file) next to the generated terragrunt.hcl or terragrunt.stack.hcl that's automatically merged into the unit or stack definition. The new unit.<name>.path and stack.<name>.path references resolve to generated paths, so you don't have to hardcode them:

# terragrunt.stack.hcl
unit "vpc" {
  source = "github.com/acme/catalog//units/vpc"
  path   = "vpc"
}

unit "app" {
  source = "github.com/acme/catalog//units/app"
  path   = "app"

  autoinclude {
    dependency "vpc" {
      config_path = unit.vpc.path
    }

    inputs = {
      vpc_id = dependency.vpc.outputs.vpc_id
    }
  }
}

Anything that's valid in a unit configuration is valid in its autoinclude block, so you can also patch catalog units with configuration they don't ship with, like retry rules:

# terragrunt.stack.hcl
unit "app" {
  source = "github.com/acme/catalog//units/app"
  path   = "app"

  autoinclude {
    errors {
      retry "transient_errors" {
        retryable_errors   = [".*Error: transient network issue.*"]
        max_attempts       = 3
        sleep_interval_sec = 5
      }
    }
  }
}

The same works for nested stacks: an autoinclude block inside a stack block patches the generated terragrunt.stack.hcl, so you can, for example, add an extra unit to one environment without forking the stack in your catalog.

Stack configurations also gained two capabilities along the way:

  • include blocks now work in terragrunt.stack.hcl files, so shared stack configuration can live in a parent folder.
  • dependency blocks can target stack directories, and the run queue expands them to the units inside. Note that this relationship only goes one way: units can depend on stacks, but stacks cannot depend on stacks or units.

See the stacks documentation for the full reference. Previously gated behind the stack-dependencies experiment, all of this is now enabled by default.

Content Addressable Store (CAS)

The Content Addressable Store (CAS) deduplicates source downloads across configurations. It addresses repositories and modules by their content, stores them locally, and serves later requests from that local store instead of repeating the fetch. This speeds up catalog cloning, OpenTofu/Terraform source fetching, and stack generation, and identical files occupy disk space once regardless of how many configurations use them.

The CAS is no longer limited to Git. It also deduplicates HTTP, Amazon S3, Google Cloud Storage, Mercurial, and SMB sources, along with OpenTofu/Terraform registry sources fetched via tfr://. See supported sources for how each one resolves and deduplicates content.

CAS is enabled by default. Use the --no-cas flag (or TG_NO_CAS=true) to opt out of it for a run:

terragrunt run --all --no-cas -- plan

Two new attributes give you finer control, and both default to off:

  • update_source_with_cas makes a generated stack self-contained. Set it on a unit, stack, or terraform block with a relative source, and terragrunt stack generate rewrites that source into a content-addressed cas:: reference, so the generated tree no longer depends on the surrounding repository layout. Catalog authors can keep relative paths in their sources and still ship a portable, reproducible stack:

    # stacks/networking/terragrunt.stack.hcl
    unit "vpc" {
      source = "../..//units/vpc"
      path   = "vpc"
    
      update_source_with_cas = true
    }

    After terragrunt stack generate, the relative path is replaced by a reference to the exact tree the CAS stored:

    # Generated output
    unit "vpc" {
      source = "cas::sha1:f39ea0ebf891c9954c89d07b73b487ff938ef08b"
      path   = "vpc"
    
      update_source_with_cas = true
    }
  • mutable controls how the CAS places fetched content on disk. By default, the CAS hard links files from its shared store into .terragrunt-cache and marks them read-only, which is fast and uses no extra space, but means the files can't be edited in place. Set mutable = true on a terraform block to copy the content instead, making the working tree safe to edit at the cost of extra I/O and disk space:

    # units/vpc/terragrunt.hcl
    terraform {
      source = "github.com/acme/catalog//modules/vpc"
    
      mutable = true
    }

Previously gated behind the cas experiment, the CAS no longer requires --experiment cas.

Redesigned terragrunt catalog

The catalog command has been redesigned. It now starts without any configuration, discovers components across your catalog repositories in the background, and streams them into the TUI as they're found.

Discovery is no longer limited to a modules/ directory; components can live anywhere in a catalog repository. To control what gets discovered, add a .terragrunt-catalog-ignore file with .gitignore-style globs for the paths you want filtered out.

Components in the TUI now carry metadata to help you navigate a large catalog: each one shows a kind label (template, stack, unit, or module) and optional tags defined in the front-matter of its README.md. From the component list, press s to open a new screen that interactively collects the values used to scaffold the component into your repository.

Previously gated behind the catalog-redesign experiment, the redesigned catalog is now the default terragrunt catalog experience.

Reading detection for local module sources

Terragrunt can select units by the files they read, which is the basis of change-based runs in CI. Previously, pointing a unit's terraform block at a local directory didn't mark the files inside that directory as read, so a change to the module wouldn't select the unit.

When a unit's source is a local module, Terragrunt now records the module's *.tf, *.tf.json, *.hcl, *.tofu, and *.tofu.json files as read by that unit, so --filter 'reading=<path>' and --queue-include-units-reading select the unit when a module file changes:

terragrunt run --all --filter 'reading=./modules/vpc/main.tf' -- plan

For files that reading detection doesn't track on its own, the new mark_glob_as_read() HCL function expands a glob and marks every matching file as read in one call:

locals {
  configs = mark_glob_as_read("${get_terragrunt_dir()}/config/{*.yaml,**/*.yaml}")
}

Existing pipelines built on --queue-include-units-reading or reading= filters may select more units than before, because changes to local module files now count as reads. Previously gated behind the mark-many-as-read experiment, these behaviors no longer require --experiment mark-many-as-read.

Skip auth during discovery with --no-discovery-auth-provider-cmd

By default, Terragrunt runs your --auth-provider-cmd once for every unit it discovers, so HCL functions that need credentials resolve correctly during parsing. In a large repository, that can mean hundreds of invocations before any unit runs, which can dominate wall-clock time on change-based runs.

The --no-discovery-auth-provider-cmd flag (env: TG_NO_DISCOVERY_AUTH_PROVIDER_CMD) skips those invocations during the discovery phase, leaving auth to run only for the units that actually execute:

terragrunt run --all \
  --no-discovery-auth-provider-cmd \
  --queue-include-units-reading=./changed-file.txt \
  -- plan

[!WARNING]
Use this only when you know parsing resolves without credentials. Units whose configuration depends on values from --auth-provider-cmd during discovery (for example, via get_aws_account_id()) will fail to parse when the flag is set.

Previously gated behind the opt-out-auth experiment, the flag now works without --experiment opt-out-auth.

Run queue displayed as a dependency tree

Before a run --all, Terragrunt lists the units it's about to run. That list now renders as a dependency tree by default instead of a flat list, with units nested under their dependencies, so the run order and the relationships between units are visible before anything executes:

The following units will be run, starting with dependencies and then their dependents:
.
├── monitoring
╰── vpc
    ╰── database
        ╰── backend-app

The header adapts to direction: dependencies come before dependents on apply, and the order reverses on destroy.

Previously gated behind the dag-queue-display experiment, the tree display no longer requires --experiment dag-queue-display.

💡 Tips Added

Tip when filtering a stack leaves nested stacks ungenerated

terragrunt stack generate --filter './my-stack | type=stack' generates only the selected
stack, not the nested stacks it contains, which can be surprising for a stack of stacks.
When a non-glob | type=stack filter leaves a stack's nested stacks ungenerated, Terragrunt
now prints a tip showing how to generate them too, for example
--filter './my-stack | type=stack' --filter './my-stack/** | type=stack'.

🐛 Bug Fixes

Fix permission denied when generated files overwrite CAS-materialized files

With the CAS enabled, Terragrunt fetches sources as read-only files. Writing a generated file over one of them no longer fails with permission denied:

  • Files from generate blocks with if_exists = "overwrite", when the module ships the target file (for example, its own versions.tf).
  • terragrunt.values.hcl, when the unit or stack source already contains one.
  • terragrunt.autoinclude.hcl, when the unit or stack source already contains one.
  • .terraform.lock.hcl, when the provider cache server updates a committed lock file during init -upgrade.

In each case, the read-only file is replaced with a writable one, and the shared CAS store is never modified.

Fix permission denied when CAS fetches a git source across filesystems

With the CAS enabled, fetching a git:: source could fail with permission denied on .git/HEAD or .git/config, sending Terragrunt back to the standard getter. It happened when the CAS store and the module's working directory sit on different filesystems, so the files are copied rather than hard-linked, and a read-only leftover from an interrupted run was in the way. Terragrunt now recovers from the leftover and completes the fetch.

Reject update_source_with_cas on a terraform block when CAS is disabled

terragrunt stack generate --no-cas now fails when a generated unit's terraform block sets update_source_with_cas = true, instead of silently emitting the unit with its relative source unchanged. The relative source has no meaning once CAS is disabled, so the generated unit could not resolve its module. This matches the existing behavior for the same attribute on unit and stack blocks, and for a run invoked with --no-cas.

Apply extra_arguments env vars when resolving dependency outputs

Resolving a dependency block's outputs now applies the env_vars from the unit's terraform extra_arguments blocks whose commands include output.

Resolve dependency outputs for units whose before_hook references a dependency

Resolving a unit's dependency outputs no longer evaluates that unit's terraform hooks, so a before_hook (or after_hook) that interpolates ${dependency.<name>.outputs.<key>} no longer fails downstream units with There is no variable named "dependency". Dependency output resolution still applies the unit's extra_arguments env_vars and source.

Select units reading added or deleted glob files in Git-based filters

Git-based filters (for example terragrunt run --all --filter '[HEAD^1...HEAD]' -- plan) now select units
that read an added or deleted file through mark_glob_as_read, even when that file lives outside the unit's
own directory. Previously only modified files outside a unit reached those units; adding or deleting a file
the glob matched left the reading unit out of the run, so its real config change was skipped. Added files are
matched against the newer reference, and deleted files against the older one where the file still exists.

mark_glob_as_read constrains its walk to a boundary

mark_glob_as_read now confines glob expansion to a boundary directory. By default the boundary is the enclosing Git repository root; outside a Git repository it is unset. A pattern whose walk would begin outside the boundary returns an error instead of expanding.

This bounds patterns that resolve higher than intended. For example, "${local.dir}/{*.yaml}" becomes /{*.yaml} when local.dir is empty, which previously walked the entire filesystem. A ? : conditional does not prevent this, because HCL evaluates both branches of a conditional before selecting one. Wrapping the call in try lets the error fall back to a default:

locals {
  files = sort(try(mark_glob_as_read("${local.dir}/{*.yaml,*.yml,*.json}"), []))
}

Pass a leading --terragrunt-boundary argument to set the boundary explicitly, for example to scope the walk to a subdirectory or to widen it to the filesystem root:

locals {
  scoped = mark_glob_as_read("--terragrunt-boundary=/etc/terragrunt", "/etc/terragrunt/{*.yaml}")
  all    = mark_glob_as_read("--terragrunt-boundary=/", "/{*.yaml}")
}

Scaffold only detects variables in the module directory

terragrunt scaffold now reads input variables from the module directory itself, matching what OpenTofu and Terraform load for a root module. Previously it scanned subdirectories too, so variable blocks defined in nested modules or examples leaked into the scaffolded inputs even though the module never exposes them.

Resolve interpolated object keys in autoinclude blocks

terragrunt stack generate now resolves interpolated object keys in autoinclude blocks (for example
{ "${local.prefix}_key" = ... }), even when the value references dependency.*. Previously the generated
unit kept the key verbatim, leaking a stack-only reference that is not valid in the unit scope.

Fix panic on non-string literal interpolation in autoinclude templates

terragrunt stack generate no longer panics when an autoinclude template interpolates a non-string literal (for example "${0}" or "${true}") alongside a dependency.* reference. The interpolated literal is now rendered to its string form (${0} becomes 0) and the dependency reference is preserved for the unit.

Resolve transitive autoinclude dependencies on a stack directory

run --all no longer fails with "does not contain a terragrunt.hcl file" when an autoinclude dependency points at a stack directory (one holding terragrunt.stack.hcl) and the unit is reached transitively through another unit. The dependency cycle check now skips a target with no unit config, matching the direct dependency case.

🧪 Experiments Updated

Six experiments completed

The following experiments graduated to general availability in this release, and the features they gated are now enabled by default:

  • stack-dependencies
  • cas
  • catalog-redesign
  • mark-many-as-read
  • opt-out-auth
  • dag-queue-display

Each feature is described in the New Features section above.

The corresponding --experiment flags (and TG_EXPERIMENT values) are no longer needed. Passing one still works, but emits a warning about the completed experiment, so you can drop it at your convenience.

Thank you to everyone who ran these experiments early and filed the feedback that got them here.

⚙️ Process Updates

Immutable releases

Starting with this release, Terragrunt releases are published as immutable releases on GitHub. Once a release is published, its tag and assets can no longer be modified or deleted, so the binary you download is guaranteed to be the same binary that was uploaded when the release was published.

See the releases process documentation for details, and Verifying releases with the GitHub CLI for how to check a download against the release attestation.

Install script verifies release attestations

The install script now checks downloaded release assets against the release attestation that ships with immutable releases. For releases starting with v1.1.0, when an authenticated GitHub CLI (v2.81.0 or later) is available, the script verifies the checksums file and the binary against the attestation before installing, and aborts if either does not match the published release. The check is skipped with a warning when gh is unavailable, too old, or unauthenticated. Use --no-verify-attestation to opt out.

Pull Requests

✨ Features
  • feat: Tip how to run a stack's units when a stack filter matches no units by @​denis256 in #​6387
🐛 Bug Fixes
📖 Documentation
🧹 Chores

[!IMPORTANT]
✂ PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from kaio6fellipe as a code owner August 18, 2026 10:44
@renovate renovate Bot added the security label Aug 18, 2026
@renovate

renovate Bot commented Aug 18, 2026 •

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: go.sum
go: downloading cloud.google.com/go/storage v1.63.0
go: downloading github.com/aws/aws-sdk-go-v2 v1.42.0
go: downloading github.com/aws/aws-sdk-go-v2/config v1.32.26
go: downloading github.com/aws/aws-sdk-go-v2/service/s3 v1.104.1
go: downloading github.com/zclconf/go-cty v1.18.1
go: downloading cloud.google.com/go/auth v0.20.0
go: downloading cloud.google.com/go/iam v1.11.0
go: downloading github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric v0.57.0
go: downloading golang.org/x/sync v0.21.0
go: downloading google.golang.org/api v0.287.0
go: downloading google.golang.org/genproto v0.0.0-20260615183401-62b3387ff324
go: downloading google.golang.org/grpc v1.82.0
go: downloading github.com/aws/smithy-go v1.27.3
go: downloading github.com/aws/aws-sdk-go-v2/credentials v1.19.25
go: downloading github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.18.29
go: downloading github.com/aws/aws-sdk-go-v2/service/signin v1.2.1
go: downloading github.com/aws/aws-sdk-go-v2/service/sso v1.31.4
go: downloading github.com/aws/aws-sdk-go-v2/service/ssooidc v1.36.7
go: downloading github.com/aws/aws-sdk-go-v2/service/sts v1.43.4
go: downloading github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.7.13
go: downloading github.com/aws/aws-sdk-go-v2/internal/configsources v1.4.29
go: downloading github.com/aws/aws-sdk-go-v2/internal/v4a v1.4.30
go: downloading github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.13.12
go: downloading github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.9.22
go: downloading github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.13.29
go: downloading github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.19.30
go: downloading github.com/mattn/go-colorable v0.1.15
go: downloading golang.org/x/exp v0.0.0-20260312153236-7ab1446f8b90
go: downloading golang.org/x/sys v0.46.0
go: downloading google.golang.org/genproto/googleapis/api v0.0.0-20260615183401-62b3387ff324
go: downloading google.golang.org/genproto/googleapis/rpc v0.0.0-20260622175928-b703f567277d
go: downloading cloud.google.com/go/monitoring v1.29.0
go: downloading github.com/GoogleCloudPlatform/opentelemetry-operations-go/internal/resourcemapping v0.57.0
go: downloading go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.69.0
go: downloading golang.org/x/net v0.56.0
go: downloading github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.7.29
go: downloading github.com/mattn/go-isatty v0.0.22
go: downloading github.com/gruntwork-io/terragrunt v1.1.1
go: downloading github.com/fatih/color v1.19.0
go: downloading golang.org/x/text v0.39.0
go: downloading go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.69.0
go: downloading github.com/felixge/httpsnoop v1.1.0
go: downloading github.com/googleapis/enterprise-certificate-proxy v0.3.17
go: downloading github.com/hashicorp/go-version v1.9.0
go: downloading github.com/klauspost/compress v1.18.6
go: downloading github.com/urfave/cli v1.22.17
go: downloading github.com/sirupsen/logrus v1.9.4
go: downloading github.com/xrash/smetrics v0.0.0-20250705151800-55b8f293f342
go: downloading charm.land/lipgloss/v2 v2.0.4
go: downloading github.com/puzpuzpuz/xsync/v4 v4.5.0
go: downloading github.com/hashicorp/terraform-svchost v0.2.1
go: downloading golang.org/x/crypto v0.53.0
go: downloading github.com/charmbracelet/colorprofile v0.4.3
go: downloading github.com/charmbracelet/ultraviolet v0.0.0-20260615092913-2399af76d5b1
go: downloading github.com/charmbracelet/x/ansi v0.11.7
go: downloading github.com/charmbracelet/x/term v0.2.2
go: downloading github.com/clipperhouse/displaywidth v0.11.0
go: downloading github.com/lucasb-eyer/go-colorful v1.4.0
go: downloading github.com/charmbracelet/x/termios v0.1.1
go: downloading github.com/charmbracelet/x/windows v0.2.2
go: downloading github.com/clipperhouse/uax29/v2 v2.7.0
go: downloading github.com/mattn/go-runewidth v0.0.24
go: downloading github.com/gruntwork-io/terragrunt v1.1.6
go: github.com/gruntwork-io/terragrunt@v1.1.6 requires go >= 1.27 (running go 1.26.2)
go: github.com/gruntwork-io/terragrunt@v1.1.6 requires go >= 1.27 (running go 1.26.2)
go: github.com/gruntwork-io/terragrunt@v1.1.6 requires go >= 1.27 (running go 1.26.2)
go: github.com/gruntwork-io/terragrunt@v1.1.6 requires go >= 1.27 (running go 1.26.2)

@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@github-actions

github-actions Bot commented Aug 18, 2026 •

Copy link
Copy Markdown

OpenSSF Scorecard — 7.2/10 ✅

Check Score Details
Binary-Artifacts 10/10 no binaries found in the repo
CI-Tests 10/10 29 out of 29 merged PRs checked by a CI test -- score normalized to 10
Code-Review 0/10 Found 0/30 approved changesets -- score normalized to 0
Dangerous-Workflow 10/10 no dangerous workflow patterns detected
License 10/10 license file detected
Pinned-Dependencies 9/10 dependency not pinned by hash detected -- score normalized to 9
Security-Policy 10/10 security policy file detected
Token-Permissions 10/10 GitHub workflow tokens follow principle of least privilege
Vulnerabilities 0/10 48 existing vulnerabilities detected

Threshold: 7 | Full report

@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed Aug 31, 2026
@renovate renovate Bot closed this Aug 31, 2026
@renovate
renovate Bot deleted the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch August 31, 2026 03:09
@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) Aug 31, 2026
@renovate renovate Bot reopened this Aug 31, 2026
@renovate
renovate Bot force-pushed the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch 2 times, most recently from 914384b to 296f894 Compare August 31, 2026 04:35
@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed Sep 2, 2026
@renovate renovate Bot closed this Sep 2, 2026
@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) Sep 3, 2026
@renovate renovate Bot reopened this Sep 3, 2026
@renovate
renovate Bot force-pushed the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch 2 times, most recently from 296f894 to 5e7618a Compare September 3, 2026 02:51
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed Sep 3, 2026
@renovate renovate Bot closed this Sep 3, 2026
@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) Sep 3, 2026
@renovate renovate Bot reopened this Sep 3, 2026
@renovate
renovate Bot force-pushed the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch from 5e7618a to 39e3c07 Compare September 3, 2026 11:32
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed Sep 17, 2026
@renovate renovate Bot closed this Sep 17, 2026
@renovate renovate Bot changed the title chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) - autoclosed chore(deps): update module github.com/gruntwork-io/terragrunt to v1 [security] (main) Sep 23, 2026
@renovate renovate Bot reopened this Sep 23, 2026
@renovate
renovate Bot force-pushed the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch from 39e3c07 to 51950a8 Compare September 23, 2026 17:16
@coderabbitai

coderabbitai Bot commented Sep 23, 2026 •

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration
  • Configuration used: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 0bdac13f-c5ca-4d3b-a6ff-8883636f90a3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

@renovate
renovate Bot force-pushed the renovate/main-go-github.com-gruntwork-io-terragrunt-vulnerability branch from 51950a8 to dc85ae8 Compare October 15, 2026 22:57
@github-actions

Copy link
Copy Markdown

Lambda integration test executed with success...

client_payload:

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants